United Public Domain Gold 2/United Public Domain Gold 2.iso/utilities/pu463.dms/pu463.adf/DOC.FILES/PP.DOC

Text File | 1993-01-30 | 24KB | 539 lines

¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

                            Powerpacker Patcher
                                Version 1.4

                     Copyright (C) 1991, Michael Berg

                            All Rights Reserved


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

INTRODUCTION

   Ever  get  tired of having to use PPMore or equivalent to view all those
Powerpacked  datafiles  you  have  scattered  everywhere?   Or maybe PPMore
doesn't  do exactly what you want?  Does your favourite ANIM player support
Powerpacked anim-files?  No?

   Well, this program should solve all your problems.  It makes PowerPacker
datafiles  act completely as if they were normal files.  In fact, with this
program  up  and  running,  there  is  not one thing you can do with normal
files,  which you cannot do with Powerpacker datafiles.  Regardless of what
programs you are using.


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

RUNNING PP

   Powerpacker  Patcher  runs from either the Workbench or the CLI.  If you
use  it  from CLI, you need not RUN it, because it detaches itself from the
current CLI process as soon as it is activated.

   If  you  run  PP  "as  is", with no arguments, it will use RAM:  for its
background  file  decrunching.   You  may  supply  PP  with  one  argument,
describing  the  path  it  should  use instead.  You may designate any path
(device  or  directory)  you like, but keep in mind that PP will be writing
and  reading  a  lot in that path, so, if possible, use a fast device (RAM:
or DH0:Temp/DecrunchDir).

   It  is  possible  for  you  to  specify  PP's  temporary  path  from the
Workbench, too:  Click (down, up) on PP's icon.  Then press and hold either
SHIFT button, and double-click (2*(down, up)) on the disk or drawer icon to
be  used for background file decrunching.  PP will let you know if you made
a mistake during startup.

   Since V1.3, PP has been told to be suspicious towards certain chances in
the  DOS.   DOS  is  usually  the primary target for link-vira, and with PP
running it can be hard for a viruschecker to establish if a virus is active
or  not.   So  PP now does its own, very simple, virus checking.  Read more
about this in the virus section below.

   Besides  the  default path, you may give an option to PP, which tells it
NOT  to  do the basic virus checking.  The option may be given to PP either
as a CLI argument like this:

    1> PP DH0:Mydir/decrunchtmp -N

   or as a "Tooltypes" item in PP's icon, if you use PP from Workbench.

   The  '-n'  (Nocheck)  is case insensitive and may appear anywhere on the
command  line.   Further,  another switch has been provided to activate the
virus  checking, even if this is actually the default.  The switch for this
is '-c' (Check).

   'Tooltypes' switches look a little different:

    CLI argument        Tooltypes equivalent
    --------------------------------------------
    -c or -C        CHECK
    -n or -N        NOCHECK

   Switches  are  "permanent".   Running PP again with another option won't
work.

   Once  Powerpacker  Patcher  has  hooked  itself  into  AmigaDOS, it will
display a small banner message to show you that everything went all right.

   Powerpacker  datafiles will begin to "act" as normal files as soon as PP
has  been activated.  Most programs, commercial and PD, will be fooled into
thinking  that  a  powerpacked  file  isn't  powerpacked at all.  When they
attempt  to  load  such  a  file,  PP will interfere and decrunch it before
passing the file along to the calling program.


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

STOPPING PP

   Simple!   Just  re-run  PP  and  the  in-memory  version  will terminate
immediately,  if  possible  (see "caveats" below).  DOS will be restored to
its  original  state,  and  Powerpacker  datafiles will again appear as ...
Powerpacker datafiles!

   Note:   PP  silently ignores any arguments (CLI or Workbench) if another
PP is already running in memory.


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

YOU'LL NEED...

   No,  no ARP or anything like that.  I just thought that I should mention
that PP no longer needs 'powerpacker.library', like Pre-1.4 versions did.


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

MEMORY NOTICE

   If  you  use RAM:  for background file decrunching then, to decrunch any
powerpacked  datafile,  you'll  need an amount of memory equivalent to what
the  file  unpacks to, plus an additional 10k (112k for a file that unpacks
to 102k).  Older versions of PP would temporarily want more than twice this
(one image in memory being written completely out to RAM:  and then freed).
PP  V1.4  uses a highly intelligent "end-to-end fragment" allocation scheme
that  allows  it to free the memory image WHILE the it is being written out
to a file in RAM:

   To  keep  it  simple:   With  PP  1.4 you can now load and decrunch much
larger  files  than you could using older versions.

   Of  course,  all of this only applies when you use a memory-based device
like  RAM:   for background file decrunching.  For other types of media, it
only  means  that  PP  returns the memory it needs (for decrunching) to the
system faster than pre-1.4 versions.

   If  PP  can't  find  the  memory  it  needs  to unpack a file (or if its
temporary  path fills up), it will simply return the original (powerpacked)
datafile  to  the calling program.  This is potentially a bit dangerous, so
in these low-memory situations, you may get some "READ ERROR" messages from
whatever  programs  you  are using.  DON'T dispare - these messages have no
other meaning than to tell you that memory is too low.  Close some windows,
terminate  some programs, delete some files from RAM:, or anything else you
can  think of.  If you get "READ ERROR" messages even if memory is NOT low,
then  it's  time  for  you to conduct a lengthy session with your favourite
disk-editor.  Because then the message is for real.  ;^)


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

SAMPLE APPLICATIONS

   Well,  what  is  it all good for, then?  Here's a small list just to get
your juices flowing:

    o Viewing Powerpacker datafiles (text)

      Simply use the TYPE command - or bring the text directly into
      your favourite editor (Memacs, TxEd, CygnusEd, whatever)

    o Viewing Powerpacker datafiles (pictures)

      Load powerpacked IFF pictures directly into DPaint (or equivalent)

    o Icons

      Yes, that's right. Go ahead and crunch all those icons. Workbench
      will never know the difference. Remember to retain the names of
      the icons - DON'T use ".info.pp". Workbench recognizes icons
      as files with a postfix of ".info".

    o Include files (header files)

      Why not go ahead and crunch all your include files for your
      compiler? (believe me, it's worth it!)

    o Try to "LIST" a directory containing powerpacked files. Pick one
      out and remember the size of it. Now "LIST" that particular file.
      You will see that the size of your file has seemingly grown. Why?
      The first LIST gives you the actual size of the file. The second
      one gives you the size of the decrunced file...  (this is really
      a side effect in PP, but quite useful in many situations)

    o Another side effect. To decrunch a file, simply COPY it from one
      location to another. The target file will be decrunched.

    o Much more

      There is no end to it. ANY kind of datafile may now be crunched,
      because it will retain its functionality 100% as long as PP is
      up and running. Script files for AmigaDOS, *.config files for
      programs that support config'ing, *.doc files for public domain
      disks, IFF pictures for DPaint, rexx scripts, makefiles, sound
      samples, printer drivers -- YOU NAME IT!


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

THEORY OF OPERATION

   It's  okay  to  skip this section if you don't care for ugly programming
details...

   It's simple, really.  PP juggles with a few DOS library vectors, so that
future  calls  to  certain  DOS  functions are rerouted through PP.  When a
file-open  request  arrives,  PP  looks at the file in question in order to
determine  the  filetype.   If it is a special file (e.g.  CON:  or NIL:) a
filehandle  from  the original DOS Open() function is returned.  Otherwise,
the  file  is  decrunched  to  a memory block, which is then flushed into a
temporary  file  on  the  RAM disk or in whatever directory you supplied PP
with when you started it.  A pointer to this new file is then returned.

    PP is, of course, intelligent enough to remove temporary files as these
are  no longer needed.  Otherwise the temporary path would soon get crowded
with  squillions  of useless files.  If PP sees that the temporary file has
been  changed  between  the  Open and the Close call, the file is rewritten
over  the  original  file,  if  possible.   The result is, of course, NOT a
crunched file.

   Future attempts to Examine() a powerpacked datafile will return the size
of  the  decrunched  file  in  the  FileInfoBlock,  and not the size of the
Powerpacker datafile itself.  Why?  Imagine an editor trying to load a text
file.  It does an Examine() to get at the filesize.  Then it allocates just
enough  memory  to  hold the file.  It then loads the file into that memory
area.   Well,  that  just  won't  work  if  the  filesize  it receives from
Examine()  is  about 50% too small.  Keep in mind that as soon as an Open()
attempt  is  made,  the file is decrunched, and will thus have a completely
different filesize!

   The above is also why some programs may report read errors in low-memory
situations.   Examine()  has  told them that the size of the file was, say,
100k, and yet they can read only 50k (if the crunch gain was 50%), which is
the  size  of  the crunched file.  This is considered to be a read error by
some programs.

   I  have  made  PP  as system friendly as possible with respect to memory
requirements.  The "end-to-end segment" allocation scheme allows PP to free
parts of an allocated memory block, namely the parts it has already written
to  a  file.   This  is  achieved  by  first allocating the entire block of
memory, and then, inside a Forbid()/Permit() pair freeing the memory again.
The  block is then reallocated (using AllocAbs()) in small, consequtive 10k
chunks.  This gives the caller a pointer to a memory block that he can free
in  equally  sized chunks.  I tried Nico's approach, which said that is was
okay to do something like this:

    m = AllocMem(1000 bytes)
    FreeMem(m,first 16 bytes)
    m += 16

    <use area from m to (m+1000-16)>

    FreeMem(m,1000-16 (the rest of the block))

   But  that  will  cause tremendous problems ("free twice" meditations) in
low-memory  situations.   (Hope  Nico  is  reading  this, so he can fix his
ppLoadData()!  -Nico, read "fragalloc.c" and "myPPLoadData.c")

   For  further  details  on  the  techniques  involved,  please  read  the
sourcecode -- it's included for just that.

   You  will  probably  notice  that the program is all in one piece.  I am
profoundly  against  "handlers".   This barbaric dissection of programs can
make  everything much more confusing and your L:  directory a heck of a lot
more  crowded.  Techies will argue, that the reason for splitting your code
in  a startup and a resident (the handler part) module is obvious; this way
only relevant code stays in memory and the startup code terminates at once.

   Well, the startup code part is rarely much more than a few K (often much
less),  and  I  myself  gladly sacrifice that small an amount of memory, if
this means that I don't have to copy two files for every executable I have.
Handler  code  is  only for *exceptional* programs, where NO OTHER solution
seems acceptable.


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

CAVEATS

   Yep,  there are a few of these, too.  First of all, you have to remember
that  PP  is  a  one way street.  This means that loading Powerpacker files
will work fine, but trying to save them again will result in a non-crunched
file.   The powerpacker.library sorely lacks a crunch function.  (Note:  At
this  point,  I'm  not considering Nico's new Powerpacker V4.0b library)

   Secondly,  when  working  with  crunched icons (or, for that matter, any
other  type  of  crunched  file),  there is a nominal performance reduction
caused  by  the  decruncher.   Don't expect crunched icons to pop up at the
same  rate  as  they  used to, or crunched include-files to get included as
fast as they used to. In pre-1.4 versions of PP, this effect could be quite
annoying  - especially for diskette based, highly fragmented files.  V1.4 &
later,  however,  use  a much more efficient algorithm.  Use of B.A.D.  and
Addbuffers is still highly recommended, though.

   Thirdly,  when  you  want  PP  to terminate, you may get a funny message
back,  saying  that  it  isn't possible to stop the in-memory PP right now.
When  you  get  this message, it is because some other program is currently
using  internal  procedures  in  PP.  Wait until all disk activity has been
completed,  and then try again.  If some faulty program "crashed" before it
could  close  all  its files, or if it simply forgot to close them, you may
not  be able to remove PP at all.  Further, if you are using other programs
that patches the same DOS vectors as PP, you have to terminate these before
PP  can  be  terminated.   If,  for  example,  you have started PP and then
SnoopDOS, you must terminate SnoopDOS before PP can be removed.

   PP  will work happily with any machine configuration I can think of.  It
has  been tested on an A500 using AmigaDOS 1.2, with .5Mb extra RAM fitted,
but  has also works happily with AmigaDOS 2.0.  Further, it has been tested
with programs such as "FragIt", "SnoopDOS", "VirusX" and "VirusChecker".  I
don't  have  a MMU, so no Enforcer checks have been made (and I don't think
that it is even possible to test PP with Enforcer).


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

PP AND VIRUSCHECKERS

   You  do  have a viruschecker, right?  Well, when you are using PP, it is
quite possible that your viruskiller will report that a virus has found its
way into memory.  Don't be alarmed, this is quite normal.  PP works because
of  library  patching,  and  does in fact look a lot like a virus.  PP hogs
these four vectors:

                  LVOOpen, LVOClose, LVOExamine, LVOWrite

   Right now I can't really think of any approach to make PP transparent to
viruscheckers.   But if at any time PP sees that someone has changed any of
the  above four vectors, it gets suspicious and displays a small message in
a  console  window.   This  message  only  appears once, even if one of the
vectors are changed yet again after that point.  This behaviour is optional
and can be turned off with the NOCHECK/-n flag.

   If  PP says that your machine is under attack by a link-virus, don't you
believe  it.  99% of the time it is simply a harmless program that needs to
patch  the  same vectors as PP.  But, unless you know EXACTLY what is going
on,  you should rely more on a virus checker than on your own judgement.  A
link-virus  is  a  very  nasty  and higly intelligent creature, and it WILL
outsmart you in most cases.  So be careful.

   PP  is  not  much  of  a  virus checker, agreed, but it does provide the
basics.   Future  releases  may  possibly  contain much more powerful virus
protection  mechanisms, so rest easy.  Get in touch if you have suggestions
on this.


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

KNOWN BUGS

   Erm..   none,  as  far as I can tell.  However, don't try to remove PP's
temporary directory while it is still running.  If you do, PP will not work
any  longer  (it won't crash your system, though, but it will act just like
it does in low-memory situations -- see "READ ERROR" comment above).

   In pre-1.4 versions, the autodetaching was sloppy.  If run from a script
(such  as  your startup-sequence), the EndCli command would refuse to close
the  CLI  window.   Moreover, any messages printed by PP would appear after
the  CLI  prompt, and that's just plain ugly.  However, 1.4 and later fixes
these problems.

   And now for the funny parts.  There is a very strange bug lurking around
somewhere  in  the Workbench.  To test this, try the following (you'll need
at least one external drive, or a hard drive):

    o Load Workbench

    o Start PP

    o Insert disks in DF0: and DF1:

    o Start any program from DF1: and keep it running. (Doesn't really
      matter what program it is, as long as it runs for some time)

    o Eject the disk in DF1: (Step 4 was to prevent WB from removing
      the DF1: icon when you remove the disk)

    o Click ONCE on DF0:'s icon

    o Press and hold either SHIFT button

    o Double-click on DF1:'s icon

   BANG! Workbench crashes (GOMF: "Code likely out of control") and summons
the  dreaded  Guru  dude.   I  discovered this peculiarity by accident, and
immediately  thought  that  PP  was at fault.  After hours of fruitless bug
hunting,  I decided to run SnoopDOS while performing the procedure outlined
above  once  again.   Without  PP  running,  of  course.   And  guess what.
Workbench crashed once again.  This can only be because of two things:

    Either,
        There's a bug in Workbench
    or
        There is the same bug in PP and in SnoopDOS

   There  are  pros  and  cons for both of these.  If you try the procedure
without  anything  funny  running  in  the background (no PP or SnoopDOS or
anything  like  that), Workbench doesn't crash, and does what you expect it
to do.

   However,  the  chance  that  exactly  the  same  bug should exist in two
programs  (by  two  different  authors)  is  very  slim.   And  SnoopDOS is
considered  to  be a textbook example of a well-behaved program (PP doesn't
do too bad, either ;^)

   Further,  Workbench  2.0  does  not  exhibit  this  behaviour,  so it is
probably the 1.2/1.3 Workbench who's at fault.

   For  now,  I'm  going to let the problem rest.  It IS a borderline case,
agreed,  but  it  could  potentially cause problems in other situations and
other  programs.   My  best  guess  is  that WB is making assumptions about
scratch register contents after certain DOS calls.  This is a no-no, as you
well know.

   If  you  have any idea what the heck is going on, don't hesitate to mail
me (see address below).


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

UNKNOWN BUGS...?

   I've  had  reports  from people who can't get PP to cooperate with ARexx
properly.  rexxarplib.library's getfile() has been reported to guru when PP
is  installed.   If  you  have Professional Page you may also run into some
trouble.

   It  is  hard  for  me to fix these kinds of problems, because it may not
always  be  PP  who  is  at fault.  Further, I don't even have the software
involved (ARexx, ProfPage, etc), so when these "inexplainable" gurus occur,
just  don't  use  PP for that particular purpose.  At least not until I can
find a way to fix things.

   During  version  changes,  it  is quite possible that I "accidently" fix
some  of  the problems, so whenever you receive a new version of PP, try it
out with your software again.  You never know...  8^)


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

REMAKING PP

   I've  enclosed  a  makefile  suitable  for  Matt  Dillons  "DMake". Just
CD  to PP's home directory, and say "DMake".  That's really all there is to
it.   Oh,  by the way, remember to set CCOPTS to nothing before issuing the
DMake  command  (the  DMakeFile  handles parameters for CC on its own).  PP
will  then be remade using large code, large data & 32 bit integers.  Large
code  & data, because other processes will be executing internal procedures
in  PP, which is virtually impossible using the small memory model.  ( Sure
it's possible, but I'm lazy!  |^) )


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

THANKS GO TO...

   Well,  who  other  than Nico François.  Nico's powerpacker.library, and,
for  that  matter,  all  the other powerpacker tools, are simply brilliant.
Credit where credit is due!


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

FUTURE RELEASES

    Version  1.0  of  PP  was  pretty  much  a beta release, and 1.1 didn't
support  all  you 2.0 guys & girls.  This version (1.4), however, should be
free  of  nasty  surprises.  There's still a multitude of possibilities for
improving PP.  Some obvious choises:

    ¤ More control on PP. Switching PP temporarily on and off while it
      is running. Possibly through hotkey combinations.

    ¤ Option to specify multiple paths for file decrunching, such that
      if one fills up, the next will be used.

    ¤ Maybe build in a screen blanking facility or PopCLI style
      hotkeys for starting a new CLI. Will this be useful, or will
      it merely interfere with the real PopCLI? Let me know.

    ¤ Improving the virus protection mechanisms

    ¤ Patching more DOS functions. DeleteFile() is a good one. This
      would enable to the user to verify the "dangerous" actions of
      a new program (a small autorequester: "ARE YOU SURE (blabla)").

    ¤ More on this: Turning PP into a simple virus protector as well.

    ¤ Integrating PPLoadSeg and PP, as suggested by Arthur Pÿpers
      (I am opposed to this proposition, however)

    ¤ Anything else that YOU would find useful!


   The  overall  effect of this program is quite astonishing.  I use it all
the  time.   Try  it - it is just fantastic to see how *.pp files act as if
they were completely normal files!


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

SHAREWARE

   PP  is  shareware.   As  you know, this means that I would like a little
something  if  you  use it frequently.  Something like $5+ (emphasis on the
PLUS) will get you the latest two updates of PP, as soon as these are ready
(more  money  probably  means faster development...).  Please read the file
'Shareware.ANGER' included in the distribution...


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

FLAMES

   If you find anything you (dis)like, mail me.  You're gonna have to write
to  me  actually  using old-fashioned ink and paper, because I'm not yet in
the  modem  business.   If you can't remember how to hold a pen, get one of
the tribe elders to show it to you.  Anyway, here's my address:

                               Michael Berg
                         Sct. Peders Gade 24A, 2th
                               8900  Randers
                                  DENMARK

(I  expect  to purchase a modem shortly, so be prepared for some real havoc
on all those BBS's 8^) )

                                 Have fun!


   Oh,  by  the  way.  I'm no good at drawing icons, and as you may already
have  seen, the icon for PP looks quite terrible.  But how do you represent
a  program  such as PP in a graphical manner?

   Please  feel free to contribute any suggestions for what the icon for PP
should  look like.  If I see something I like (data or merely ideas), I may
even use it with future releases of PP.


¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
                         __
                        ///
                    __ ///
                    \\X// AMIGA - There Can Be Only One
                     ¯¯¯  ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨